{% extends "base_site.html" %}

{% block body_tag %}
	<body id="dnsviz-home">
{% endblock %}

{% block crumbtrail %}
<div id="crumbtrail"><a href="/">DNSViz Home</a> &raquo; <a href="/doc/">Documentation</a> &raquo; DNSSEC visualization</div>
{% endblock %}

{% block maincontent %}
	<h3>DNSSEC visualization</h3>

	<ul>
		<li><a href="#zones">Zones</a></li>
		<li><a href="#dnskey-rrs">DNSKEY RRs</a></li>
		<li><a href="#ds-rrs">DS RRs</a></li>
		<li><a href="#nsecnsec3-rrs">NSEC/NSEC3 RRs</a></li>
		<li><a href="#rrsets">RRsets</a></li>
		<li><a href="#rrsigs">RRSIGs</a></li>
		<li><a href="#node-status">Node status</a></li>
	</ul>

	<h4><a name="zones">Zones</a></h4>
	<table>
		<tr><td><img src="{{ STATIC_URL }}images/dnssec_legend/zone.png" alt="Zone cluster" /></td><td><p>Nodes in DNSViz are clustered by the <strong>zone</strong> to which the represented information belongs. Each zone is labeled with the name of the zone origin and the time at which the zone was last analyzed.</p></td></tr>
	</table>

	<h4><a name="dnskey-rrs">DNSKEY RRs</a></h4>
	<table>
		<tr><td><img src="{{ STATIC_URL }}images/dnssec_legend/dnskey.png" alt="DNSKEY node" /></td><td><p><strong>DNSKEY</strong> resource records (RRs) are included in zone data, so resolvers can validate signatures made by the corresponding private keys.  These signatures are returned in DNSSEC responses accompanying DNS data.</p><p>In DNSViz, each DNSKEY RR is represented as a single DNSKEY node in the zone cluster to which it belongs.  The DNSKEY RR for the <span class="domain">example.com</span> zone has <strong>algorithm</strong> 5 (RSA/SHA-1) and <strong>key tag</strong> 12345, both of are used to identify the DNSKEY.  Each DNSKEY node is decorated based on the attributes and roles of the corresponding DNSKEY RR, as described in the following entries.</p></td></tr>
		<tr><td><img src="{{ STATIC_URL }}images/dnssec_legend/dnskey-published.png" alt="Published DNSKEY" /></td><td><p>A dashed border indicates that the DNSKEY is <strong>published only</strong>.  That is, the DNSKEY is not being used in any signing capacity.</p><p>  Publishing a DNSKEY before it is actively used to sign data is a common for maintenance mechanisms such as key rollovers, as documented in RFC 4641.</p></td></tr>
		<tr><td><img src="{{ STATIC_URL }}images/dnssec_legend/dnskey-sep.png" alt="DNSKEY with SEP bit" /></td><td><p>A gray fill indicates that the <strong>SEP</strong> (secure entry point) bit is set in the <strong>flags</strong> field of the DNSKEY RR.</p><p> This bit typically designates a DNSKEY for usage as a <strong>key signing key (KSK)</strong>, a DNSKEY that is only used to sign the DNSKEY RRset of a zone and provides secure entry to a zone via DS RRs or a trust anchor at the resolver.</p></td></tr>
		<tr><td><img src="{{ STATIC_URL }}images/dnssec_legend/dnskey-revoke.png" alt="DNSKEY with revoke bit" /></td><td><p>A thick border indicates that the <strong>revoke</strong> bit is set in the <strong>flags</strong> field of the DNSKEY RR.</p><p>Resolvers which implement the trust anchor rollover procedures documented in RFC 5011 recognize the revoke bit as a signal that the DNSKEY should no longer be used as a trust anchor by the resolver.  For a DNSKEY to be properly revoked, it must also be self-signing (i.e., used to sign the DNSKEY RRset), which proves that the revocation was made by a party that has access to the private key.</p></td></tr>
		<tr><td><img src="{{ STATIC_URL }}images/dnssec_legend/dnskey-trustanchor.png" alt="DNSKEY designated as trust anchor" /></td><td><p>A double border indicates that the DNSKEY is being used by DNSViz as a <strong>trust anchor</strong>.</p><p>By default DNSViz uses the the KSKs for the root zone and the <a href="https://dlv.isc.org/">DNSSEC Look-aside Validation (DLV) registry</a> provided by <a href="http://www.isc.org/">Internet Systems Consortium (ISC)</a> as the exclusive trust anchors.  Either of these may be de-selected, and any arbitrary DNSKEYs may be configured as trust anchors in the free-form options field.</p></td></tr>
		<tr><td><img src="{{ STATIC_URL }}images/dnssec_legend/dnskey-warning.png" alt="DNSKEY with PMTU accessibility issues" /></td><td><p>If a yellow warning symbol appears in the DNSKEY node, it is because one or more authoritative servers have a <strong>path MTU (PMTU)</strong> problem.  Such servers are attempting unsuccessfully to send a payload larger than what that of which they are capable.</p></td></tr>
		<tr><td><img src="{{ STATIC_URL }}images/dnssec_legend/dnskey-error.png" alt="DNSKEY with inconsistent accessibility" /></td><td><p>If a red warning symbol appears in the DNSKEY node, it is because the DNSKEY RR is not being returned from one or more responsive authoritative servers.  This may be because the servers are <strong>out of sync</strong> or because the server implementation(s) <strong>do not support the DNSKEY RR type</strong>.</p></td></tr>
	</table>
		
	<h4><a name="ds-rrs">DS RRs</a></h4>
	<table>
		<tr><td><img src="{{ STATIC_URL }}images/dnssec_legend/ds.png" alt="DS node" /></td><td><p><strong>DS</strong> (delegation signer) RRs exist in the parent of a signed zone to establish secure entry into the zone.  If a DNSKEY is registered in the ISC DLV registry, then the node is displayed as a <strong>DLV</strong> RR in the <span class="domain">dlv.isc.org</span> zone, though the behavior is the same as if it were a DS in the parent zone.</p><p>In DNSViz DS RRs with the same DNSKEY algorithm and key tag are typically displayed as a single node since they usually correspond to the same DNSKEY RR with different digest algorithms.  The DS for <span class="domain">example.com</span> has algorithm 5 and key tag 12345, and maps to the corresponding DNSKEY RR with digest algorithms 1 (SHA1) and 2 (SHA-256).</p><p>In this example, the blue color of the arrow pointing from DS to DNSKEY indicates that the digest contained in each of the DS RRs is valid, and corresponds to an existing DNSKEY in <span class="domain">example.com</span>.  However, other circumstances may exist, which are shown in the following entries.</p></td></tr>
		<tr><td><img src="{{ STATIC_URL }}images/dnssec_legend/ds-baddigest.png" alt="DS with bad digest" /></td><td><p>A dashed red line from DS to DNSKEY indicates that a DNSKEY exists matching the algorithm and key tag of the DS RR, but <strong>the digest of the DNSKEY in the DS RR does not match</strong>.</p></td></tr>
		<tr><td><img src="{{ STATIC_URL }}images/dnssec_legend/ds-nodnskey.png" alt="DS with no matching DNSKEY" /></td><td><p>A dashed yellow line from DS to a DNSKEY also filled with yellow indicates that <strong>no DNSKEY matching the algorithm and key tag</strong> of the DS RR exists in the child zone.</p><p>Extraneous DS RRs in a parent zone do not necessarily constitute an error. Sometimes they are deliberately pre-published before their corresponding DNSKEYs, as part of a KSK rollover, as documented in RFC 4641.  However, for every DNSSEC <strong>algorithm</strong> in the DS RRset for the child zone, a matching DNSKEY must be used to sign the DNSKEY RRset in the child zone, as per RFC 4035.</p></td></tr>
		<tr><td><img src="{{ STATIC_URL }}images/dnssec_legend/ds-error.png" alt="DS with inconsistent accessibility" /></td><td><p>If a red warning symbol appears in the DS node, it is because the DS RR is not being returned from one or more responsive authoritative servers.  This may be because the servers are <strong>out of sync</strong> or because the server implementation(s) <strong>do not support the DS RR type</strong>.</p></td></tr>
	</table>
		
	<h4><a name="nsecnsec3-rrs">NSEC/NSEC3 RRs</a></h4>
	<table>
		<tr><td><img src="{{ STATIC_URL }}images/dnssec_legend/nsec.png" alt="NSEC node" /></td><td><p>If a there are no DS RRs for child zone in the zone's signed parent, that constitutes an <strong>insecure delegation</strong>, meaning that there is no secure link for authenticating the child zone given trust at the parent zone.  However, a resolver must be able to prove the insecure delegation, that is, that no DS RRs exist for the child zone.  This is done with RRs of type <strong>NSEC</strong> or <strong>NSEC3</strong>, for authenticated denial of existence or hashed authenticated denial of existence, respectively.</p><p>In DNSViz the NSEC or NSEC3 RR(s) returned by a server authoritative for the parent zone to prove that DS RRs for the child zone do not exist are represented by a single Ndiamond-shaped node, labeled with either NSEC or NSEC3, depending on which method the zone is signed with.  An edge extends from the NSEC or NSEC3 node to the child zone.  If the edge is solid blue, then the NSEC or NSEC3 RRs returned are <strong>sufficient</strong> to prove that DS RRs do not exist for the child zone.</p></td></tr>
		<tr><td><img src="{{ STATIC_URL }}images/dnssec_legend/nsec-insufficient.png" alt="NSEC insufficient to prove non-existence" /></td><td><p>A solid red edge from the NSEC or NSEC3 node to the child zone indicates that the NSEC or NSEC3 RRs provided by the servers authoritative for the parent zone are <strong>insufficient</strong> to prove that DS RRs for the child zone do not exist.</p></td></tr>
		<tr><td><img src="{{ STATIC_URL }}images/dnssec_legend/nsec-missing.png" alt="NSEC not returned by servers" /></td><td><p>If an NSEC or NSEC3 node is filled with red, then <strong>no servers are providing any NSEC or NSEC3 RRs</strong> to prove the non-existence of DS RRs.</p></td></tr>
		<tr><td><img src="{{ STATIC_URL }}images/dnssec_legend/nsec-error.png" alt="NSEC not returned by some servers" /></td><td><p>If a red warning symbol appears in the NSEC or NSEC3 node, it is because the NSEC or NSEC3 RR(s) are <strong>not being returned</strong> from one or more responsive authoritative servers.  This may be because the server implementation(s) <strong>do not support</strong> DNSSEC or do not support NSEC3.  For example, NSEC3 is not implemented in versions of <a href="http://www.isc.org/software/bind">ISC BIND</a> prior to 9.6.</p></td></tr>
	</table>

	<h4><a name="rrsets">RRsets</a></h4>
	<table>
		<tr><td><img src="{{ STATIC_URL }}images/dnssec_legend/rrset.png" alt="RRset node" /></td><td><p><strong>RRsets</strong> are represented as rectangles with rounded corners.  At the moment this includes SOA, A, AAAA, MX, and CNAME RR types.</p><p>RRsets that are specific to DNSSEC, such as the DNSKEY, DS, RRSIG, NSEC and NSEC3 RR types, are represented as other node types, as specified elsewhere in this guide.</p></td></tr>
		<tr><td><img src="{{ STATIC_URL }}images/dnssec_legend/alias.png" alt="Alias edge" /></td><td><p><strong>Aliases</strong> are represented by a black edge from one RRset (the <strong>alias</strong>) to another (the <strong>target</strong>).</p></td></tr>
	</table>

	<h4><a name="rrsigs">RRSIGs</a></h4>
	<table>
		<tr><td><img src="{{ STATIC_URL }}images/dnssec_legend/rrsig.png" alt="RRSIG edge" /></td><td><p>Each <strong>RRSIG</strong> RR contains the cryptographic signature made by a DNSKEY over an RRset.  Using the DNSKEY with the same algorithm and key tag as the RRSIG, the RRset which was signed, and the RRSIG itself, a resolver may determine the correctness of the signature and authenticate the RRset.</p><p>In DNSViz RRSIGs are represented as directed edges from the DNSKEY which made the signature to the RRset that was signed.  The edges in the example denote RRSIGs made by the <span class="domain">example.com</span> DNSKEY with algorithm 5 and key tag 12345, which cover the following (from left to right): the <span class="domain">example.com</span>/SOA RRset; and the NSEC RRset(s) proving non-existence of DS RRs for some child zone; and the DS RRset for a (different) child zone.</p><p>The color and style of RRSIGs is also significant.  A blue edge indicates a valid RRSIG.  Other configurations are shown in the following entries.</p></td></tr>
		<tr><td><img src="{{ STATIC_URL }}images/dnssec_legend/rrsig-dnskey.png" alt="RRSIG covering a DNSKEY RRset" /></td><td><p>Just like other RRsets, a DNSKEY RRset is signed as an RRset, which comprises all the collective DNSKEY RRs at the zone apex.  In some DNSSEC implementations, multiple DNSKEYs sign the DNSKEY RRset, even though only a subset is designated as a secure entry point into the zone, matching DS records in the parent zone.  Such DNSKEYs often have the SEP bit set, but it is not required.</p><p>Rather than create a mesh of edges between all DNSKEY nodes that sign the DNSKEY RRset, DNSViz does the following.  For every DNSKEY signing the DNSKEY RRset, a self-directed edge is added to the node, indicating that the DNSKEY is <strong>self-signing</strong>.  Additionally, if the DNSKEY provides a <strong>secure entry point</strong> into the zone, then edges are drawn from it to other DNSKEYs to illustrate the chain of trust.  If there is no secure entry point, then edges are drawn from DNSKEYs with the <strong>SEP bit set</strong> to other DNSKEYs.</p></td></tr>
		<tr><td><img src="{{ STATIC_URL }}images/dnssec_legend/rrsig-bogus.png" alt="RRSIG with bogus signature" /></td><td><p>A solid red edge indicates an RRSIG in which the cryptographic signature is <strong>bogus</strong>.</p></td></tr>
		<tr><td><img src="{{ STATIC_URL }}images/dnssec_legend/rrsig-expired.png" alt="Expired or premature RRSIG" /></td><td><p>A solid purple edge indicates that an RRSIG is invalid because it is outside its <strong>validity period</strong>, defined by <strong>inception</strong> and <strong>expiration</strong> date fields in the RRSIG RR.</p></td></tr>
		<tr><td><img src="{{ STATIC_URL }}images/dnssec_legend/rrsig-mismatched.png" alt="RRSIG mismatched or not returned" /></td><td><p>A dashed red edge indicates that either an RRSIG is <strong>not returned</strong> by one or more authoritative servers or that the RRSIG is an <strong>invalid match</strong>.  If authoritative servers are not returning RRSIGs appropriately, it may be because their server implementations do not support DNSSEC or it is not enabled in their configurations</p><p>An invalid match may be because the <strong>signer</strong> field in the RRSIG does not match the name of the zone apex or because the RRSIG was made by a <strong>DNSKEY</strong> with the revoke bit set.  These are disallowed by RFCs 4035 and 5011, respectively.</p></td></tr>
		<tr><td><img src="{{ STATIC_URL }}images/dnssec_legend/rrsig-nodnskey.png" alt="RRSIG with no matching DNSKEY" /></td><td><p>A dashed yellow edge indicates that the DNSKEY corresponding to the algorithm and key tag in an RRSIG was <strong>not found</strong>, so the correctness of the RRSIG cannot be verified.  This doesn't necessarily indicate an error; as long as there are RRSIGs which can be validated, then extraneous RRSIGs are simply ignored.  Also, there are situations when RRSIGs must be published to prime caches prior to publishing the corresponding DNSKEYs, such as with an algorithm rollover, as documented in RFC 4641-bis.</p></td></tr>
	</table>

	<h4><a name="node-status">Node status</a></h4>
	<table>
		<tr><td><img src="{{ STATIC_URL }}images/dnssec_legend/secure.png" alt="Secure node" /></td><td><p>Beginning at the DNSKEYs designated as trust anchors, DNSViz traverses the nodes and edges in the graph to classify each node as having one of three DNSSEC statuses, depending on the status of the RRset which it represents: <strong>secure</strong>, <strong>bogus</strong>, or <strong>insecure</strong>.  In DNSViz, node status is indicated by the color of the nodes (Note that there isn't always a one-to-one mapping between node and RRset, but the node status will be consistent among all nodes comprising an RRset.  An example is the DNSKEY nodes for a zone, which all have the same status even though the DNSKEY RRset is split among different nodes).</p><p>Nodes with blue outline indicate that they are <strong>secure</strong>, that there is an unbroken chain of trust from anchor to RRset.</p></td></tr>
		<tr><td><img src="{{ STATIC_URL }}images/dnssec_legend/bogus.png" alt="Bogus node" /></td><td><p>Nodes with red outline indicate that they are <strong>bogus</strong>, that the chain of trust from an anchor has been broken.</p></td></tr>
		<tr><td><img src="{{ STATIC_URL }}images/dnssec_legend/insecure.png" alt="Insecure node" /></td><td><p>Nodes with black outline indicate that they are <strong>insecure</strong>, that no chain of trust exists; if any anchors exist then an insecure delegation is demonstrated to prove that no chain should exist from the anchors.  This is equivalent to DNS without DNSSEC.</p></td></tr>
	</table>
{% endblock %}
